In the 3rd Generation Partnership Project (3GPP), work is ongoing on specifications of the UMTS Terrestrial Radio Access Network (UTRAN) evolution (E-UTRA) as part of the Long Term Evolution (LTE) effort.
In LTE, scheduling is modelled in the Medium Access Control (MAC) layer and resides in the eNodeB (eNB). The scheduler assigns radio resources, also called Resource Blocks (RB), for the downlink (assignments) as well as for the uplink (grants) using the Physical Downlink Control CHannel (PDCCH).
The radio uplink is the transmission path from a terminal, which may also by referred to as a User Equipment (UE), to a base station, or an eNodeB. A downlink is the inverse of an uplink, i.e. the transmission path from the eNodeB to the terminal.
For uplink scheduling, the eNodeB needs information about the current state of the buffers in the terminal, i.e. if and how much data the terminal has in its priority queues. This information is sent from the terminal to the eNodeB either as a 1-bit Scheduling Request (SR) or by a Buffer Status Report (BSR). The Scheduling Requests are transmitted on a control channel such as e.g. Physical Uplink Control CHannel (PUCCH) or Radio Access CHannel (RACH) while the BSR are transmitted on the data channel such as e.g. Physical Uplink Shared CHannel (PUSCH), mostly together with user data.
Precise and up-to-date scheduling information allows more accurate scheduling decisions, and can help to optimize the use and management of radio resources and to improve capacity. However, the accuracy of the information provided by the terminal is limited by the granularity of the buffer status reports, by the frequency of the Scheduling Request and buffer status report transmissions and by the delay between the reception of the Scheduling Request or buffer status report and the scheduling decision.
For delay sensitive services with periodical packet arrival, such as Voice over Internet Protocol (VoIP), the likelihood that the buffer status information is outdated when it is used is high. It is likely that additional data has arrived since the buffer status report was transmitted. It is also likely that the buffer will be emptied frequently and therefore the only available information will be a one bit Scheduling Request.
With incorrect uplink information, the scheduler will provide either a too large grant, which then results in the terminal transmitting padding and may reduce system capacity, or a too small grant, which may lead to Radio Link Control (RLC) segmentation and increase transmission delay.
Uplink buffer status reports are needed in order for the base station to know the amount of data waiting for transmission in the terminal. In E-UTRAN uplink buffer status reports refer to the data that is buffered for a Logical Channel Group (LCG) in the terminal. Four LCGs and two formats are used for reporting in uplink:
A short Buffer Status Report format, which contains the buffer size of one LCG and a long Buffer Status Report format, which contains the buffer sizes of all four LCGs.
Uplink buffer status reports are transmitted using MAC signalling.
According to the previously known solution in LTE, a framework for buffer status reporting is specified. Buffer status reporting is used by the terminal to report to the eNodeB the amount of data stored in its buffers for transmission. The eNodeB uses these reports to allocate resources to the terminal, and to prioritize resource allocation between different terminals.
The terminal triggers a regular Buffer Status Report and Scheduling Request when uplink data becomes available for transmission and if this data belongs to a radio bearer, i.e. logical channel, group with higher priority than those for which data already existed in the buffer or if the terminal buffers were empty just before this new data became available for transmission.
In case the transport block size is larger than the amount of data available for transmission at the time of assembly of the MAC Protocol Data Unit (PDU) for transmission, one Buffer Status Report can also be including, also referred to as a padding Buffer Status Report. In case the terminal has data for more than one logical channel but a Buffer Status Report format that can only contain information about one logical channel, a truncated format is also available as padding Buffer Status Report.
Another type of Buffer Status Report, the Periodic Buffer Status Report, provides a timer-based trigger per terminal to handle reporting for continuous flows.
FIG. 1 shows a simplified example of what might happen when a scheduling principle adopted for best-effort data services is applied to VoIP, resulting in unnecessary delay and many grant transmissions. The scheduling request triggers a small grant that only allows a Buffer Status Report and a small amount of data. While waiting for the grant, another packet arrives. So first two grants are spent to transmit one single packet and a packet that could have been transmitted with the second grant has to wait for another grant.
The current buffer status reporting framework has several shortcomings, such as e.g. the Buffer status information is likely to be outdated when used in scheduling decisions. Also, buffer status information is likely to be based on only a 1-bit Scheduling Request when used in scheduling decisions. Further, a solution to determine buffer status in a more efficient way would be most useful.